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ABSTRACT 

As  the  army  focuses  on  bringing  fewer  men  to  the 
forefront  of  the  battle,  robotic  assets  will  become  more 
prevalent.  The  soldier  will  need  to  be  able  to  control 
these  assets  from  a  portable,  rugged,  and  robust 
Operator  Control  Unit(OCU).  It  is  important  that  the 
soldier's  mobility  and  situational  awareness  not  be 
adversely  affected  by  this  task.  Although  many  of 
today's  fielded  systems  are  wearable  or  fit  within  a  brief 
case,  they  still  can  cause  a  deterioration  in  the  soldiers 
overall  performance.  A  lightweight,  non-intrusive  solution 
is  required  with  an  interface  that  is  easy  to  use,  but 
robust  enough  to  control  multiple  assets  and  their  many 
functions.  This  paper  will  focus  on  the  in-house 
development  of  an  OCU  for  a  lab-robot  that  parallels  the 
OCU  developed  to  support  the  Dismounted  Mule 
operations  that  were  a  part  of  the  Vetronics  Technology 
Integration(VTI)  effort  in  February,  March,  and  April  of 
2003. 

INTRODUCTION 


The  technology  and  requirements  for  OCUs  are 
continuously  evolving.  Early  systems  featured  up  to  five 


operators  and  large  control 
stations,  such  as  the  1970s 
Soviet  lunar  robot  “Lunokhod". 
Modern  units  normally  are 
configured  to  fit  inside  a 
briefcase  sized  enclosure  (see 
Figure  1)  or  are  man 
wearable,  such  as  the  one 


displayed  in  Figure  2.  As  the  Figure  1:  Briefcase  ocu 


battlefield  continues  to  move 


Figure  2:  Man  - 
Wearable  OCU 


towards  a  more  urban  setting,  it  is 
advantageous  for  these  systems  to 
become  less  cumbersome.  With  the 
ever-increasing  advancements  in 
processor  speed  it,  is  realistic  to  expect 
that  OCUs  will  continue  to  decrease  in 
size  while  still  increasing  in  capability. 

To  this  end,  members  of  the  Tank 
Automotive  Research,  Development,  & 
Engineering  Center  (TARDEC) 


Vetronics  Robotic  Mobility  Team  have  begun  in-house 


development  of  a  prototype  PDA  OCU  for  autonomous 


and  tele-operational  interfacing  with  an  Unmanned 
Ground  Vehicle(UGV).  Members  of  Carnegie  Mellon 
Robotics  Institute  have  developed  an  OCU  for  the 
dismounted  solider  experiments  within  the  Vetronics 
Technology  Integration  2003  demonstration. 

OCU  MODELS 

This  paper  will  focus  on  two  OCUs  currently  under 
development.  Both  OCUs  use  similar  hardware 
(COMPAQ  iPAQ,  Wireless  LAN,  Serial  GPS),  but  have  a 
different  focus.  The  TARDEC  model  is  based  on  a 
robot-centric  perspective.  The  CMU  model  is  based 
upon  a  controller-centric  perspective;  focused  on  aiding 
the  dismounted  soldier  as  well  as  monitoring  and 
controlling  semi-autonomous  vehicles. 

TARDEC  MODEL 


The  following  section  details  the  TARDEC  in-house  effort 
towards  developing  an  OCU  for  its  lab-robot. 


Concept  Development 


In  an  effort  to  do  in-house  testing  of  mobility  and  sensor 
algorithms  developed  by  contractors,  and  to  further  their 


own  research  efforts,  TARDEC 
started  developing  a  lab-robot  in 
October  of  2001.  The  robot  was 
designed  to  incorporate  various 
sensors  such  a;  laser  radar 
(LADAR),  DAY  TV,  Differential 
Global  Positioning  Systems  (DGPS), 
Digital  Compass,  and  Non-Contact 


Optical. 


As  the  robotic  platform  neared  Figure  3:  Lab  Robot 

completion,  mission  needs  changed 

and  the  original  OCU  concept  of  a 

Laptop  and  Desktop-emulation  software  was  abandoned. 

In  an  effort  to  parallel  the  OCU  development  of  the  VTI 

contractor,  the  TARDEC  effort  opted  for  a  new  platform 

based  on  a  commercial  PDA. 


The  new  OCU  would  need  to  encapsulate  the  following 
functions:  Mode  Control,  Complete  Manual  Functions, 

I 


Comprehensive  Diagnostics,  Limited  Debugging,  and  the  iPAQ.  Finally,  the  iPAQ  was  the  PDA  selected  by  the 
Follower  Capability.  VTI  contractor. 


Mode  Control 

The  lab-robot  has  multiple  modes  of  operation  depending 
on  what  mission  is  being  run,  what  sensors  are  being 
tested,  and  what  algorithms  are  being  developed.  These 
various  modes  and  their  parameters  need  to  be 
interfaced  through  the  OCU. 

Compiete  Manual  Functions 

The  OCU  needs  to  be  able  to  control  all  of  the  various 
sub-systems  individually  through  a  manual  control 
functionality  of  their  interface.  This  can  be  as  simple  as 
jogging  the  speed-controllers,  to  as  complex  as  sending 
a  test  message  through  the  IP  client. 

Comprehensive  Diagnostics 

Each  of  the  various  sensors  on  the  robot  has  one  or 
more  dedicated  processes.  These  processes  send  out 
diagnostic  messages  to  the  IP  server.  The  OCU  needs 
to  be  able  to  read  and  filter  these  messages. 


What  other  components  are  needed? 

After  selecting  the  PDA,  two  pieces  of  hardware  were 
required  -  a  wireless  PC  card  to  connect  to  the  robots  IP 
server  and  a  serial  GPS  card  to  get  position  data  for  the 
foilower  mode.  In  order  for  the  iPAQ  to  support  these 
two  cards,  a  third  piece  of  hardware  would  be  required  - 
a  dual  slot  PC  card  expansion  pack. 

The  ‘2.4GHz  Wireless  Compact  Flash  Card  Kit’  from 
SMC  was  selected  as  the  network  adapter.  This  was 
based  on  SMC  being  the  manufacturer  of  the  robot’s 
wireless  hub  and  their  support  of  the  iPAQ’s  Operating 
System  (OS).  The  current  card  runs  the  802.11b 
standard,  but  may  need  to  be  upgraded  due  to 
bandwidth  iimitations  with  the  streaming  video. 

The  ‘World  Navigator’  from  Teletype  GPS  was  selected 
for  the  GPS  receiver.  This  card  was  selected  because  of 
the  easy  access  to  positioning  data  and  avaiiability  of 
tech-support.  As  an  added  benefit,  this  particular  model 
has  built  in  support  for  a  DGPS  correction  signai. 


Limited  Debugging 

From  a  development  standpoint,  it  would  be  nice  to  have 
access  to  limited  debugging  functions  from  the  OCU,  so 
that  every  probiem  with  the  robot  wouldn’t  require  the 
downtime  involved  with  linking  up  to  the  development 
system. 

Follower  Capability 

One  of  the  robot’s  missions  wili  be  to  follow  the  operator. 
This  is  currently  done  by  dropping  GPS  breadcrumbs 
among  other  things.  To  accomplish  this,  the  OCU  will 
need  to  know  its  current  GPS  position. 

Hardware  Specifications 


Why  the  iPAQ? 


After  iooking  at  many  of  the  avaiiable  commercial  PDAs 
and  Pocket  PCs;  we  eventually  selected  the  Compaq 
iPAQ.  This  was  based  on  a  number 
of  factors.  First,  the  iPAQ  has  one  of 
the  larger  usable  viewing  areas. 

They  don’t  restrict  a  portion  of  the 
screen  to  text  entry  like  the  Palm 
Series.  Second,  Compaq  offers  a  lot  Figure  4:  ipaq 
of  options  and  add-ons,  as  do  many  of 
the  vendors  supporting  their  product  line.  Third,  the 
iPAQ  runs  Windows  CE  2.0  as  a  standard  configuration. 
This  was  the  OS  of  choice  for  our  development 
environment.  Fourth,  there  was  a  very  impressive  OCU 
at  the  AUVSl  summer  conference  in  Orlando,  FL  using 


Finally,  a  dual  slot  PC  card  expansion  pack  was  required 
so  that  the  iPAQ  could  access  both  PC  cards. 

Software  Specifications 

In  order  to  develop  and  code  a  robust  OCU  three  criteria 
needed  to  be  met:  a  solid  foundation  through  a  proven 
development  environment,  proven  and  easily  accessible 
peripheral  interfacing  through  established  drivers,  and 
reliable  communications  with  the  robot  to  be  controlled. 

A  Proven  Development  Environment 

The  TARDEC  OCU  was  developed  under  ‘MobileVB’ 
from  AppForge.  This  development  package  offered 
many  benefits:  First,  they  have  a  great  reputation  in  the 
PDA  Appiication  Deveiopment  Industry  and  a  very 
comprehensive  online  support  program.  Second,  by 
being  an  add-on  to  Microsoft’s  Visual  Basic,  they  offer  a 
look  and  feel  that  already  has  a  wide  acceptance  level. 
Third,  a  majority  of  the  lab-robot’s  processes  were  coded 
in  part  or  in  full  in  Visual  Basic.  This  allowed  for  a  lot  of 
commonality  and  software  reuse.  Finally,  they  offered 
built-in  support  for  all  of  the  OCU’s  specified  hardware 
making  interfacing  a  breeze. 

Peripherai  Interfacing 

By  taking  advantage  of  the  inherent  capabiiities  of  the 
development  environment,  interfacing  to  the  wireless 
network  adapter  and  the  GPS  card  was  almost 
seamless.  The  client/server  package  developed  for  the 
lab-robot  was  very  easy  to  port  over  to  the  OCU 
environment;  as  a  resuit,  the  wireless  adapter  was 


running  in  a  matter  of  days.  And  the  GPS  card  spoke  in 
a  serial  National  Electrical  Manufacturers  Association 
(NEMA)  format  that  was  easily  processed  by  the 
development  environment.  All  in  all,  the  interfacing  to 
the  OCU’s  peripherals  was  made  easy  by  the  selection 
of  a  robust  development  environment. 

Communication  with  the  Lab  Robot 

All  of  the  robot’s  processes  are  built  on  an  application  of 
a  custom  TCP/IP  client/server  package  developed  for 
this  project.  By  choosing  the  OCU’s  development 
environment  to  be  compatible  with  this  application,  it  was 
possible  to  greatly  increase  the  speed  of  development, 
as  well  as  the  reliability  of  the  end  product.  The  OCU 
currently  sees  communications  in  the  2.5-4Mbps  range, 
over  a  distance  of  about  200m.  This  is  typical  and  to  be 
expected  of  the  802.11b  standard.  Although,  due  to  low 
frame  rate  on  the  streaming  video,  the  hardware  may 
need  to  be  changed  to  802.11a  or  802.1 1g  to  alleviate 
the  bandwidth  crunch. 

Human  Factors 

The  TARDEC  approach  to  OCU  development  is  robotic¬ 
centric.  That  is,  this  OCU  was  designed  with  a  specific 
robot  in  mind:  in  this  case,  the  Lab  Robot.  A  major 
advantage  to  this  approach  is  that  by  knowing  the  details 
of  the  robot,  you  can  customize  the  OCU  to  a  very  fine 
degree.  The  design  goals  for  the  TARDEC  OCU  are 
operator  independence,  intuitive  interface,  and  robust 
control. 

Operator  Independence 

The  OCU  was  designed  so  that  it  would  not  need  to  be 
reconfigured  when  it  was  passed  from  operator  to 
operator.  A  left-handed  user  would  interface  with  the 
OCU  in  the  exact  same  fashion  as  right-handed  person 
would.  The  majority  of  this  type  of  development  was 
done  by  the  manufacturer  of  the  iPAQ,  but  the  screen 
layout  and  control  placement  was  done  with  this  concept 
in  mind. 

Intuitive  Interface 

This  concept  incorporates  two  fundamental  principles  - 
recognizable  controls  and  predictable  progression.  The 
first  part  of  this  concept  can  be  met  by 
following  the  standards  established  by 
Microsoft  Windows©.  Therefore,  it  is 
possible  to  layout  a  form  such  that  the 
operator  recognizes  every  push¬ 
button,  combo-box,  and  selection  list 


for  what  it  is.  They  will  recognize  the  Figure  5: 
control  and  know  how  to  use  it.  The  tardecocu 
second  part  can  be  met  by  making 
screen  changes  in  a  predictable  fashion.  It  would  be 
quite  difficult,  if  not  impossible,  to  place  everything 


needed  to  control  a  robot  on  one  screen.  Therefore, 
logical  progression  must  be  used  to  traverse  the 
multitude  of  screens  needed  for  complete  control.  If  all 
of  the  robot’s  sensors  are  accessible  from  the  PDA,  they 
should  be  accessible  in  a  similar  fashion. 

Robust  Control 

This  is  accomplished  by  making  key  features  available 
as  they  are  needed  and  keeping  the  operators  input  to  a 
minimum.  If  a  sensor  is  not  being  used  in  a  given  mode, 
than  it  should  not  waste  screen  space  by  being 
displayed.  If  a  specific  function  is  required,  the  operator 
shouldn’t  have  to  search  through  multiple  menus  to  find 
it. 

CMU  MODEL 

Carnegie  Mellon  approached  the  dismount  OCU  system 
from  the  perspective  that  today’s  commercial  of  the  shelf 
(COTS)  parts  are  sufficiently  cheap  and  powerful  to  allow 
a  demonstrable  and  viable  OCU  to  be  constructed 
quickly  and  inexpensively.  Our  reliance  on  COTS 
components  allowed  us  to  focus  on  developing  a  strong 
application  framework  that  gave  substantial  flexibility  in 
interacting  with  the  Dismount  and  the  Robotic  Vehicle. 
This  flexibility  proved  to  be  critical  when  integrating  the 
OCU  with  the  vehicle. 

Concept  Development 

The  guiding  principle  behind  the  OCU  developed  by 
Carnegie  Mellon  for  the  2003  VTI  demonstration  is  that 
for  humans  to  interact  successfully  with  Robotic  Vehicles 
the  interaction  must  be  simple  and  high  level. 

This  desire  for  simplicity  manifested  itself  in  a  number  of 
ways  throughout  the  application  interface.  First,  for  any 
human  to  successfully  interact  with  a  robotic  vehicle 
there  must  be  a  simple  and  effective  set  of  commands 
available  to  the  user.  Secondly,  access  to  the 
commands  through  the  interface  should  be  consistent. 
Thirdly,  the  view  of  the  data,  specifically  Vehicle 
positions  and  Dismount  positions,  must  be  clear  and 
concise. 

Simple  Commands 

When  considering  the  tasks  that  need  to  be 
accomplished;  there  are  only  three  necessary  to  a 
Dismount  Follower  application:  Goto,  Follow  Me,  and 
Stop.  In  addition  to  these  commands,  the  user  is 
permitted  to  select  the  maximum  speed  of  the  vehicle. 
This  OCU  is  not  intended  to  give  the  operator  tele¬ 
operation  control  of  the  vehicle.  The  direct  mechanical 
control  of  the  vehicle  is  left  to  vehicle  specific 
mechanisms. 


Figure  6:  Robot  control  interface 


Interface  Consistency 

The  Dismount  OCU  itself  has  only  one  operational  mode; 
however,  the  Robotic  Vehicle  it  is  maneuvering  with  can 
be  executing  different  commands  (as  outlined  above).  In 
each  operational  mode,  different  commands  are  sensible 
to  execute.  One  school  of  thought  holds  that  only  the 
applicable  options  should  be  shown  to  the  user  at  any 
given  time.  This  can  be  confusing  to  the  user.  The  CMU 
system  always  presents  the  same  set  of  options  to  the 
user;  however,  options,  which  are  not  available  to  the 
user,  are  “grayed  out”  so  that  there  is  no  impression  that 
an  option  is  “lost.”  The  interface  available  to  the 
Dismount  is  menu  driven  and  uses  the  native  “tap  and 
hold”  mechanism  to  trigger  display.  When  the  user  taps 
and  holds  on  the  screen,  whatever  is  closest  to  the 
location  of  the  tap,  displays  it’s  configuration  menu  (see 
Figure  6,  above). 


Figure  7:  Dismount  and  Robot  dispiayed  in  Aerial  Image  with  each 
entity  displaying  its  path  in  red. 


In  the  Dismount  Following  application,  the  goal  is  to  be 
able  to  tell  the  Robotic  Vehicle  to  follow  behind  the 
Dismount  by  a  distance  that  will  not  keep  the  Vehicle  in 
constant  visual  contact.  Further,  for  the  system  to  be 
effective  and  usable,  it  cannot  be  the  case,  that  the 
Dismount  must  constantly  “mind”  the  Robotic  follower. 
These  two  statements  form  the  backbone  of  the 
requirements  for  the  Data  View.  To  accomplish  these 
goals,  a  set  of  overhead  maps  was  chosen  for  display. 
The  maps  that  were  chosen  were  an  Aerial  Image,  a 
Topographic  Map,  and  a  Digital  Elevation  Map  (DEM). 
Only  one  map  from  the  set  is  displayed  at  a  time.  On  the 
currently  displayed  map,  the  paths  of  the  Dismount  and 
the  Robotic  Vehicle  are  displayed  (see  Figure  7).  This 
method  of  information  display  allows  the  user  to 
understand  the  present  and  historical  situation  quickly  so 
that  the  system  can  be  set  into  motion  and  then  ignored 
unless  the  Robotic  Vehicle  notifies  the  dismount  that  it  is 
in  trouble.  For  the  purposes  of  this  application  the 
Robotic  Vehicle  is  considered  to  be  “in  trouble”  if  it  gets 
stuck:  cognitively  or  mechanically. 

Hardware  Specifications 

The  hardware  selection  process  was  driven  by  two  facts. 
First  of  all  this  is  a  system  for  use  by  Dismounted 
Soldiers.  Because  of  this,  the  entire  system,  including 
batteries,  had  to  be  small  enough  to  be  worn.  The 
second  consideration  was  cost  and  speed  of 
development.  As  mentioned  above,  a  system  composed 
of  COTS  components  worked  quite  well  for  development 
and  fielding. 

We  broke  the  necessary  hardware  into  the  three 
following  categories:  computing  and  display  devices, 
localization  devices,  and  communications  devices. 

For  the  computing  and  display  device  we  selected  a 
Compaq  iPAQ.  There  were  a  few  reasons  for  this 
choice.  First  of  all,  the  iPAQ  has  great  flexibility  in 
interacting  with  other  hardware  systems  since  it  supports 
industry  standard  interfaces:  Serial,  USB,  and  PCMCIA. 
Of  particular  interest  to  us  was  the  ease  of  integrating 
PCMCIA  cards.  The  number,  variety,  and  low  cost  of 
PCMCIA  cards  made  the  use  of  them  very  attractive. 
Secondly,  the  iPAQ  comes  with  Windows  CE™  natively 
installed  in  ROM.  Microsoft  also  provided  a  free  compiler 
for  the  Windows  CE^'^  environment  when  development 
of  this  application  was  started. 

For  localization,  we  experimented  with  2  different 
devices.  First  of  all  we  used  an  integrated  GPS  and 
dead  reckoning  unit.  This  unit,  the  Dead  Reckoning 
Module  produced  by  Point  Research  Corporation,  is  self- 
contained  and  internally  integrates  GPS  information  and 
dead  reckoning  information  using  a  Kalman  filter.  The 


unit  behaved  reasonably,  in  most  field  experiments, 
generating  acceptable  position  estimates  even  during 
GPS  outages.  The  major  problem  with  the  unit,  for  the 
Robotic  Follower  application,  is  that  it  trades  accuracy  of 
positioning  for  extended  battery  life.  This  reduced 
accuracy  was  a  problem  when  in  the  field  with  a  Robotic 
Vehicle. 


Figure  8:  The  CMU  OCU  system 


When  the  Dead  Reckoning  Module  failed  to  give  a  good 
enough  path  for  robotic  following,  a  GPS  only  unit  was 
used.  The  selected  GPS  device  is  a  Wide  Area 
Augmentation  System  (WAAS)  and  had  tremendous 
accuracy.  In  practice  we  got  1  meter  accuracy  much  of 
the  time.  In  the  future,  it  may  well  be  worth  the  effort  to 
replace  the  GPS  unit  in  the  Dead  Reckoning  Module  with 
a  higher  accuracy  GPS  unit. 

For  communications,  the  immediate  thought  was  to  use 
802.1 1(b)  wireless  communications.  These  cards  are 
ubiquitous,  inexpensive,  and  effective.  For  the  field  trial, 
an  access  point  was  placed  onto  the  robotic  vehicle.  In 
the  future  it  is  worth  considering  replacing  an  access 
point  based  network  with  an  ad  hoc  peer  to  peer  network 
to  remove  the  infrastructure  requirements  from  the 
system.  It  is  not  reasonable  to  expect  that  the  Dismount 
Soldier  will  be  able  to  install  a  network  infrastructure  as 
the  robot  follows  him  in  the  field. 

Software  Specifications 

The  software  for  the  Dismount  Soldier  OCU  was 
designed  from  the  very  beginning  to  be  robust  and 
extensible.  To  maximize  the  robustness  of  the 
application  we  decided  to  develop  in  C++  and  use  the 
Model  View  Control  architecture  (MVC).  The  MVC 
architecture  is  well  suited  to  this  application  since  it  has  a 
number  of  research  items.  The  ability  to  encapsulate  the 
research  items  in  a  sensible  way  allowed  us  to  easily 


substitute  different  versions  of  components  for  testing 
purposes. 

A  further  advantage  of  the  MVC  architecture  is  that  the 
Dismount  Soldier  OCU  must  be  very  small  and  portable 
thereby  imposing  strict  limits  on  the  View  layer  of  the 
application.  Because  the  View  layer  is  independent  of 
the  application  control  (Control  layer)  and  the  data 
(Model  Layer),  a  new  view  can  be  constructed  on  the 
same  application  base.  This  would  allow  a  “command” 
view  of  the  data;  using  a  larger  display  and  showing  a 
wider  ranging  view  of  the  situation  than  any  single 
Dismount  could  have. 

One  important  design  decision  was  that  the  Dismount 
OCU  would  treat  the  Robotic  Vehicle  as  a  black  box. 

The  communications  between  the  OCU  and  the  Robotic 
Vehicle  were  simply  structured  commands  and  status 
messages  sent  over  a  wireless  Ethernet  connection 
using  a  UDP/IP  (datagram)  socket.  This  method  of 
integration  was  selected  so  that  any  robot  that  can 
support  a  UDP/IP  socket  and  process  the  simple 
commands  can  be  integrated  with  the  Dismount  OCU 
without  changing  the  OCU  itself. 

For  development  and  compilation,  we  used  the 
Embedded  Visual  C++®  3.0  development  environment 
and  Microsoft®  ActiveSync®.  This  environment  was  the 
most  sensible  choice  since  it  has  good  User  Interface 
support  for  the  Windows  CE®  platform. 

Human  Factors 

The  CMU  OCU  development  was  focused  on  creating  a 
simple,  easy  to  understand  system  that  was  not  tightly 
tied  to  any  single  robotic  vehicle.  The  CMU  OCU  effort 
was  never  focused  on  debugging  the  Robotic  Vehicle, 
but  rather  on  getting  the  Dismount  Soldier  to  be  able  to 
maximize  the  effectiveness  of  Robotic  Vehicles  in  the 
field. 

Field  Results 

The  Carnegie  Mellon  Dismount  OCU  went  into  the  field 
as  part  of  the  VTI  demonstration  that  took  place  in 
February  and  March  of  2003.  In  the  field  a  number  of 
things  were  learned  and  areas  for  improvement  of  the 
system  were  found. 

Previous  to  the  field  experiments,  the  Dead  Reckoning 
Module  was  the  localization  device  of  choice  for  the 
OCU.  When  in  the  field  though,  it  became  apparent  that 
the  Dead  Reckoning  Module’s  power/accuracy  trade  off 
sacrificed  too  much  accuracy  to  be  useful  for  a  Dismount 
Following  Application.  In  consultation  with  the  vendor,  it 
is  clear  that  adjustments  can  be  made  to  the  unit  which 
will  increase  the  unit’s  accuracy  while  decreasing  it’s 
battery  life.  A  further  investigation  of  this  device  and  its 
capabilities  would  be  appropriate. 
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There  is  a  constant  struggle  between  map  detail  and 
map  size  in  the  application.  While  the  iPAQ  is  a  powerful 
device,  its  memory  is  not  boundless  and  is  far  less  than 
is  available  on  a  standard  desktop  machine.  This  trade 
off  in  detail- and  size  forced  us  to  select  map  resolutions 
on  the  order  of  8  meters  per  pixel.  This  resolution  was 
acceptable  for  most  tasks  that  the  OCU  was  to  handle; 
however,  it  made  directing  the  robot  to  “Goto”  a  location 
in  the  map  a  difficult  task.  With  practice  the  operator 
became  more  adept  at  selecting  specific  points  in  the 
map:  however,  a  few  simple  improvements  in  the  user 
interface  would  aid  in  this  greatly.  One  improvement 
would  be  the  addition  of  a  compass.  Showing  a 
compass  heading  for  the  dismount  in  the  display  would 
greatly  increase  the  speed  at  which  the  map  can  be 
understood.  The  map  is  always  oriented  with  north  at 
the  top  of  the  display  though  that  is  not  the  way  that  the 
dismount  is  always  facing.  With  a  displayed  compass 
heading  for  the  dismount  it  should  be  easier  to  reconcile 
the  real  world  with  the  displayed  representation.  The 
other  item  that  should  help  in  this  regard  is  higher 
resolution  maps. 

Another  thing  that  became  quite  obvious  is  that  the 
Dismount  OCU’s  greatest  liability  is  power.  The  reliance 
on  COTS  components  created  a  system  that  was  power 
hungry.  In  commercial  uses  the  expectation  is  that  the 
user  is  never  too  far  from  a  power  source  and  can  plug 
the  system  in  to  charge  when  the  power  gets  low.  When 
in  the  field,  power  is  much  harder  to  come  by  and  the 
runtimes  between  recharges  must  be  much  higher.  The 
CMU  OCU  was  targeting  a  4-hour  runtime  without 
requiring  any  recharges.  This  turned  out  to  be  more 
challenging  than  anticipated.  Due  to  desired  runtime  and 
the  power  hungry  components  the  battery  weight  in  the 
system  was  easily  over  50%  of  the  total  system  weight. 
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CONCLUSION 

The  capability  to  control  robotic  assets  from  a 
commercial  PDA  is  a  realistic  option  today.  Current 
limitations  in  wireless  communication,  which  adversely 
affect  the  video  feedback  and  other  large  packets  of 
data,  will  be  overcome  with  advancements  within 
wireless  communication.  Additional  ruggedisation  of  the 
PDA  will  be  required  to  protect  the  hardware  from  the 
harsh  conditions  it  would  likely  encounter  in  any  fielded 
operation.  As  the  capability  of  processors  continues  to 
advance,  the  size  of  OCUs  will  continue  to  decrease  and 
the  capability  will  continue  to  increase.  The  in-house 
testing  of  the  TARDEC  OCU  has  produced  encouraging 
results.  The  system  will  be  operational  tested  in  the 
June  2003  International  Ground  Vehicle  Competition. 
Collaboration  with  TARDEC  and  Carnegie  Mellon  may 
occur  as  part  of  future  VTI  Demonstrations  (2004  or 
2006). 
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